The present invention relates to the field of database management systems, and more specifically, to evaluating integrity of database workload transactions.
An important function affecting the integrity of a database management system is the deterministic behavior of concurrent database transactions, more specifically table locking, availability and integrity, such as table page read-write accessibility during IUD actions (insert, update or delete). In database systems, locks are employed when more than one database user wants to access data concurrently. Locks are used to maintain data integrity and avoid data corruption when users attempt to modify the same data at the same time.
Standard locking engines allow a database user to modify data upon a granted lock request where exclusive access to the data exists until the lock is disengaged. If the database user needs to lock a database table for which they do not have a lock, they must request a lock from the database management system. Consequently, locking not only provides exclusivity to modify data but also prevents other database users from accessing uncommitted data actions. Normally during a data update, database users request a commit statement to make data modifications permanent. For example, the invocation of a commit to complete a database transaction, such as information read or write actions, makes all associated modifications visible to other users of the database.
Snapshot isolation (SI) is an alternative approach to concurrency control that takes advantage of multiple versions of each data item. A transaction T running under SI sees the database state as produced by all the transactions that committed before T started, but no effects are seen from transactions that overlap with T. This means that SI does not suffer from inconsistent reads. Transaction T will successfully commit only if no updates T has made conflict with any concurrent updates made since T's start. In a database management system (DBMS) using SI for concurrency control, read-only transactions are not delayed because of concurrent update transactions' writes, nor do read-only transactions cause delays in update transactions. Typically, locking is accomplished by a lock manager engine that is included in database management systems where lock acquisition actions are fully synchronized in nature.
However, in database transactional systems, a user may still progress in a transaction without knowing for certain that access to potentially shared data is serialized against modifications by other transactions. This specific anomaly that may occur is known as “write skew.”